Hi, thanks for the contribution! I'd like to understand your use case a bit better to get more context – why do you need margins taken into account?

I'll explain my position on the matter at the moment. When I wrote this library, I deliberately excluded margins from the calculations. The primary reason for this was simple (and perhaps naïve): The use cases of the product I was building at the time. Our users got contextual selections based on the element that was visually closest to where they were clicking. Margins are by definition invisible and were therefore excluded, as they really only contribute to the position of an element, not its dimensions. This is also reflected in the DOM Element.getBoundingClientRect() method, which doesn't include margins.

There are some other concerns I have with including margins in the calculations:

1. Margin collapsing could produce some confusing results. For example, picking a point that's within the collapsed margin areas of two elements would be calculated as "touching" both elements, when visually it's between them.
2. Elements with display: inline will still report their top/bottom margin when inspected, but the margin is not applied. This throws out the calculations and requires checking the display property's value for every element.

Additionally, the way this PR is currently written (as a base change rather than a new option), it's a breaking change. Anyone using it at the moment is relying on the calculations not including margins. Having it suddenly include margins could cause interesting bugs.

It's entirely possible that you have a use case I haven't considered so far, so I'd like to know more about what you're after.

Cheers,
Gil